home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / uri / 92nov.min next >
Text File  |  1993-02-17  |  8KB  |  202 lines

  1. Editor's Note:  Minutes received 12/4/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Alan Emtage/Bunyip
  7.  
  8. Minutes of the Uniform Resource Identifiers Working Group (URI)
  9.  
  10. The Agenda for the first meeting of the URI Working Group was approved.
  11. The Charter for the Group was reviewed and approved.  It was noted that
  12. the ``Goals and Milestones'' may need to be changed in the future
  13. depending on the progress in this very new area.
  14.  
  15. Peter Deutsch/Bunyip who was initially named to co-Chair the Group
  16. resigned the position in order to follow a more activist role and avoid
  17. any potential conflict of interest.  Jim Fullton/CNIDR was installed as
  18. new co-Chair.  However before stepping down Peter took the opportunity
  19. to make a few personal observations and commitments:
  20.  
  21.  
  22.    o Peter has offered to co-author an overview paper along with Chris
  23.      Weider.  This paper would propose a possible architecture to the
  24.      Group describing the use and the form of the various Uniform
  25.      Resource objects such as URI's (Uniform Resource Identifiers),
  26.      URL's (Uniform Resource Locators) and URSN (Uniform Resource Serial
  27.      Numbers) and how the would interoperate.
  28.  
  29.    o Peter gave a basic overview of his ideas about what the UR objects
  30.      looked liked.  By his definitions:
  31.  
  32.       -  A URL identifies a particular object on the network and is
  33.          composed of a named scheme (e.g., FTP, WAIS, Gopher) and
  34.          information specific to that scheme.  It was noted that this
  35.          idea already exists in a similar form in the World Wide Web
  36.          (WWW) system, and has been codified in a paper by Tim
  37.          Berners-Lee/CERN.
  38.       -  A URSN can be broken down into a ``virtual user'' and an actual
  39.          serial number.  Related topics were the issue of the
  40.          ``producer'' of an network object and the ``owner''; some
  41.          possible schemes for implementation of the virtual user
  42.          (whois++ handle, X.500) ; and what the serial number would
  43.          looked like (possibly an MD5 checksum and other methods).
  44.  
  45.      It was decided in the interests of time that further discussions
  46.      should be carried out on the mailing list.
  47.  
  48.  
  49. The paper currently titled ``Universal Resource Locators'' by Tim
  50. Berners-Lee was reviewed and the following comments were made:
  51.  
  52.  
  53.    o The use of the term ``protocol'' in the document is ambiguous given
  54.      the context of the IETF and should be replaced or more specifically
  55.      defined.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. o The use of the term ``name'' was considered to be unclear and again
  64.   should be clarified.  It was suggested that it be removed and
  65.   another term used in its place.
  66.  
  67. o The document should be written as a ``standalone'' unit.  However,
  68.   the objects described therein should be viewed as part of a larger
  69.   architecture and an explicit description of their purpose should be
  70.   added.  It was suggested that the document could be further
  71.   generalized from a _perceived_ WWW bias.
  72.  
  73. o The question of the ``partial form'' of the URL brought heated
  74.   discussion between two factions:  one which wanted the removal of
  75.   the form altogether and one which suggested their continued
  76.   existence with restrictions.  Some consensus developed around the
  77.   idea that partial forms could be used internally for individual
  78.   information systems but should not be used when exchanged
  79.   externally.  It was decided that further discussion should occur on
  80.   the mailing list.
  81.  
  82. o Consensus was reached that the document should specifically state
  83.   URLs are to be considered transient and should not be used in
  84.   static objects (hardcopy documents, etc.).  Their use as references
  85.   should be specifically discouraged.  Such references was considered
  86.   to be in the domain of the URSN, whatever they ultimately look
  87.   like.
  88.  
  89. o The paper should describe the general scheme being proposed without
  90.   reference to particular systems (other than as examples).  All
  91.   detailed descriptions of individual systems should be put in an
  92.   appendix.  It was decided that the most likely repository for the
  93.   individual definitions would ultimately be the Internet Assigned
  94.   Numbers Authority (IANA) but that the original document may propose
  95.   the definitions for a basic range of services (such as FTP).
  96.  
  97. o It was suggested by Thomas Hacker/UMich that to the OSF DCE DFS
  98.   (Open Software Foundation Distributed Computing Environment
  99.   Distributed File System).
  100.  
  101. o Mitra/Pandora (mitra@pandora.sf.ca.us) proposed a ``fragment
  102.   specifier'' scheme to be incorporated into the URL document.  It
  103.   was decided that detailed discussion of this was best left to the
  104.   mailing list.
  105.  
  106. o Other points were:
  107.  
  108.    -  Some of the text and examples did not agree
  109.    -  The use of percentage signs should be reviewed on the mailing
  110.       list.
  111.    -  Use of blank characters was again questioned.
  112.  
  113.   All were referred back to the mailing list for further discussion
  114.  
  115.  
  116.                                 2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. A discussion about URI's followed.  The questions that were raised were:
  123.  
  124.  
  125.   1. Given the current definitions what _exactly_ does URI mean?
  126.  
  127.        o Alan Emtage suggested that they may be defined as URI = URL +
  128.          URSN + ``Uniform Resource Representator'' (URR) since the
  129.          current definitions of URL and URSN do not give sufficient
  130.          information for a user/client to determine if in fact the
  131.          information available is useful and that such things as
  132.          filename extensions are not a reliable method of determining
  133.          content format (and in the case of processes is meaningless).
  134.          However he declined to be committed on what exactly these URR's
  135.          would look like.
  136.        o It was suggested that the concept of the ``URI'' may be defunct
  137.          now since it as been decomposed into several constituent parts.
  138.  
  139.  
  140.   2. The proposal that John Kunze/UCBerkeley had made on the mailing
  141.      list previously was briefly discussed and it was suggested that he
  142.      and Clifford Lynch/UC co-author an alternate document to that
  143.      produced by Peter Deutsch and Chris Weider, more from the
  144.      perspective of the library community.  John's proposal for access
  145.      lists, descriptive fields, functional types and a ``UR Citation''
  146.      were suggested as being better handled in detail on the mailing
  147.      list.
  148.  
  149.   3. In addition to the document describing the general UR system, Peter
  150.      Deutsch and Chris Weider have agreed to co-author a paper proposing
  151.      the structure of URSN's.
  152.  
  153.  
  154. Attendees
  155.  
  156. Jules Aronson            aronson@nlm.nih.gov
  157. Jodi-Ann Chu             jodi@uhunix.uhcc.hawaii.edu
  158. Naomi Courter            naomi@concert.net
  159. John Curran              jcurran@bbn.com
  160. Peter Deutsch            peterd@bunyip.com
  161. Alan Emtage              bajan@bunyip.com
  162. Jill Foster              jill.foster@newcastle.ac.uk
  163. Joan Gargano             jcgargano@ucdavis.edu
  164. Thomas Hacker            hacker@citi.umich.edu
  165. Deborah Hamilton         debbie@qsun.att.com
  166. Alisa Hata               hata@cac.washington.edu
  167. J. Paul Holbrook         holbrook@cic.net
  168. Ole Jacobsen             ole@interop.com
  169. Edward Krol              e-krol@uiuc.edu
  170. John Kunze               jak@violet.berkeley.edu
  171. Clifford Lynch           calur@uccmvsa.ucop.edu
  172. Janet Marcisak           jlm@ftp.com
  173. Michael Mealling         michael@fantasy.gatech.edu
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Mitra                    mitra@pandora.sf.ca.us
  182. Charlotte Mooers         mooers@nnsc.nsf.net
  183. Mark Needleman           mhn@stubbs.ucop.edu
  184. Kate O'Mara              kate@acfcluster.nyu.edu
  185. Pete Percival            percival@indiana.edu
  186. Joyce K. Reynolds        jkrey@isi.edu
  187. Bradley Rhoades          bdrhoades@mail.mmmg.com
  188. Richard Rodgers          rodgers@nlm.nih.gov
  189. Jennifer Sellers         sellers@nsipo.arc.nasa.gov
  190. Jane Smith               jds@jazz.concert.net
  191. Simon Spero              simon_spero@unc.edu
  192. Craig Summerhill         craig@cni.org
  193. Claudio Topolcic         topolcic@cnri.reston.va.us
  194. Janet Vratny             janet@apple.com
  195. Chris Weider             clw@merit.edu
  196. Moira West               mjw@cert.org
  197. Yung-Chao Yu             yy@qsun.att.com
  198.  
  199.  
  200.  
  201.                                    4
  202.